1. Field of the Invention
In a typical construction design, a set of construction plan drawings are generated, usually with a computer-implemented tool, such as an architectural CAD (Computer Aided Design) software product. Disadvantageously, the various elements and materials of the construction project, for example, windows, doors, skylights, acrylic glass blocks and the like, are priced out in estimating the cost of the job in a completely separate process, and usually only by one manufacturer. This separate process very disadvantageously adds a significant amount of time and effort to the process of generating a construction job price. Also very disadvantageously, because different construction materials of varying quality and cost can generally be used on the same construction job or project, the cost amounts that are set forth on a price schedule that is generated by this separate process can vary by a very wide margin. Further, and also disadvantageously, in the event that the price schedule needs to be changed, for example, due to cost overruns, competitive bidding and/or other factors, a new price schedule must be generated, with an additional significant investment of time and effort involved for each such revision. Again, this adds a significant amount of extra expense to a construction project, and this typical process limits the flexibility in selected various construction material's for contractors and end-use customers.
It is important to provide a price, rather than an estimate, for a proposed construction project. In order for a bank (or other lending institution) to approve a construction loan for a proposed construction project, the bank generally requires an accurate price for the construction project, and will not rely upon an estimate, because estimates are often extremely inaccurate. If a bank does accept an estimate, and the estimate turns out to be lower than the final price for the construction project, the bank, which has control in such a situation, may then additionally charge large points and/or fees for the construction loan, substantially raising the price of the construction project, which is very undesirable. If the estimate turns out to be lower than the final price, this often results in construction cost overruns, construction time delays and dissatisfaction of customers.
Most of the time when architectural plans are drawn, the plans are drawn inaccurately. If an architectural plan is drawn inaccurately, and a price is provided for a corresponding construction project, this situation generally presents significant problems with respect to construction cost overruns, construction time delays and the satisfaction of customers (homeowners or building owners).
It was a goal of the present invention to solve the above-described problems.
2. Description of the Art
Wakelam et al. (U.S. Pat. No. 6,859,768 B1) describe a computer-implemented automated building design and modeling system (“DMES system”) that includes a database (column 4, lines 30-32) that provides a central source for all design and construction information for a construction project (abstract, column 1, lines 57-67, and claim 1). Ordinary elements and massing elements are assembled into a building model according to a sequential assembly hierarchy, “thus assembling a complete building model automatically . . . ” (abstract and claim 11). Software for a commercially-available “cost estimating system” (represented as 112 in the figures), as well as software for several other systems that may be employed in a network implementation of the DMES system, is stored on a hard drive of a computer (FIG. 1 and column 7, lines 45-62). The “cost estimating system” produces a cost estimate (not a price), which is implemented using Ice 2000 computer software.
In contrast with the present invention, Wakelam et al. do not describe the production of a “price quote” or a “price schedule.” It is clear from a detailed review of Wakelam et al. that the systems and processes described therein only produce an estimate (a “cost estimate”), which is for a production of an entire building. (See, for example, FIGS. 2g, 2h, 2i, 2j, 2k and 6b, the abstract, Appendix A, and column 1, lines 51-54, column 3, lines 42-46, column 7, lines 37-43, column 9, lines 8-31, and the claims of Wakelam et al.).
The “cost estimating system” that is described by Wakelam et al. for producing cost estimates is one of several different systems that are implemented with the DMES system described therein, and is a known computer software named “Ice 2000” that is commercially available from MC2 Management Computer Controls, Inc., and described on the MC2 Management Computer Controls, Inc. mc2-ice web site (column 7, lines 55-58).
Also, in contrast with the present invention, Wakelam et al. does not describe an ability to determine a price quote or price schedule for only one or two construction plan elements, such as only a window, or only a window and a door. It is clear from a detailed review of Wakelam et al. (including FIGS. 1-6) that the processes and systems that are described therein only provide a “cost estimate” (only a “ball park” figure regarding what the actual cost of designing and building a building may be) for the production of an entire building (i.e., not for individual construction products, such as a window, a door, an acrylic glass block, a sky light or the like). The cost estimate for the entire building includes cost estimate data for a wide variety of materials, components and labor, such as electrical devices, equipment and wiring, lights, HVAC systems, elevators, and man hours of labor involved in the fabrication of the building, as well as construction products, such as windows and doors.
As a result of the above difference, the methods and systems of the present invention are advantageously much more versatile than the methods and systems that are described by Wakelam et al. For example, the present invention can be employed in small or large residential or commercial remodeling construction projects, as well as for constructing entire new residential or commercial buildings. In contrast, the methods and systems described by Wakelam et al. can only be used for the construction of an entire new building.
Also in contrast with embodiments within the present invention, Wakelam et al. does not describe a process or system having a plug-in (add-on) computer software code that runs as an internal component within a software design tool on a local computer, such as architectural CAD, but rather uses a stand alone, interview-based system, and a commercially available cost estimation software named Ice 2000. It is clear from a detailed review of Wakelam et al. that the processes and systems that are described therein are stand-alone processes and systems that can work in a network along with the DMES system.
Moreover, Wakelam et al., which describe a very complicated system that is employed to construct an entire building using a series of multiple tiers and hierarchies, teach away from the use of architectural CAD (a software design tool) by stating the following at Column 4, Lines 38-59, and Column 18, Lines 7-23, respectively:                “ . . . In contrast to a conventional CAD tool, which uses software algorithms that scan and sort the locations and extents of all three-dimensional primitive geometries in a building model and compares all of the locations thereof for potential overlaps, the DMES system of the present invention performs clash detection, or interference checking, by cross-checking the location and extents of a current instance of an object against only those other existing instances in the model, i.e., the spatial database, and adjusting its position if necessary before assembling it into the model. This automatic clash detection is part of the assembly code included in each massing element and each element uses its own specific functions to determine the parameters of a clash and the rules by which to reposition the instance. This process has a small incremental impact on the speed of the assembly process, but completely removes the need for a series of long clash detection exercises after the model is complete.” [Emphasis added.]        “ . . . In contrast to a conventional CAD tool, which uses software algorithms that scan and sort the locations and extents of all three-dimensional primitive geometries in a building model and compares all of the locations thereof for potential overlaps, the DMES system of the present invention performs clash detection, or interference checking, by cross checking the location and extents of the current instance against only those other existing instances in the model and adjusting its position if necessary before assembling it into the model. This automatic clash detection is part of the assembly process in each massing element and each element uses its own specific functions to determine the parameters of a clash and the rules by which to reposition the instance. This process has a small incremental impact on the speed of the assembly process, but completely removes the need for a series of long clash detection exercises after the model is complete.” [Emphasis added.]        
Further, in contrast with embodiments within the present invention, Wakelam et al. does not describe a process or system that employs a zip code of a construction site to access price data from a web site on a remote server system, an external or other physical storage medium or the like. Wakelam et al. does not describe a process or system that employs a web site that includes price data for a purchase of one or more construction plan elements in a geographical location within a zip code or otherwise. Further, in contrast with the “cost estimates” described by Wakelam et al., the price data described herein can be relied upon to purchase one or more construction plan (or other) elements.
In contrast with embodiments within the processes and systems of the invention, the processes and systems that are described by Wakelam et al. are very complicated (perhaps because an entire building is being assembled), and include an assembly hierarchy having five or more tiers.
Further, in contrast with embodiments within the present invention, Wakelam et al. do not describe: (a) an insertion of a price schedule into a construction plan; (b) a price schedule that contains a list of construction plan elements with corresponding price quotes; (c) a placing of an order to purchase one or more construction plan elements; (d) a placing of an order to purchase one or more construction plan elements using a local computer or a web site on a remote server, or both; (e) a placing of an order to purchase one or more construction plan elements using a credit card and a local computer or a web site on a remote server, or both; or (f) a creation of a price schedule including one or two construction plan elements.
U.S. Pat. No. 6,446,053 B1 (Elliott) describes a computer-implemented method and system for producing a proposal for a construction project (title). The system includes a central site with various databases and a user site connected for electronic communication over a networked communication system such as the Internet (abstract). The user site includes a computer having stored in memory an application that enables a user to develop a construction proposal including a detailed graphical model and a detailed cost estimate model, have the proposal submitted electronically over a networked communication system to a construction professional for a bid, and receive a response on the proposal from the construction professional over the networked communications system (abstract). The application educates the user as it guides the user through a series of construction phases and steps, prompting the user to input critical information and make appropriate selections throughout the series of phases and steps (abstract). The method and system provide a proposal and a cost “estimate,” not a final price (abstract).
In contrast with embodiments within the methods and systems of the present invention, Elliott: (1) does not employ a plug-in (add-on) computer software code that runs as an internal component within a software design tool on a local computer, such as architectural CAD (but rather uses a stand alone, interview-based system); (2) does not insert parametric symbols into a construction plan; (3) does not, using an add-on computer software code, transmit data corresponding to inserted parametric symbols from a local computer over the Internet to a remote server system; (4) use a zip code and an add-on computer software code to access price data from a web site on a remote server system; or (5) determine from price data a price quote for each of several construction elements, but rather provides only a cost estimate.
Both Wakelam et al. and Elliott use stand alone computer software for cost estimation that does not include an add-on (plug-in) computer software code. Wakelam et al. uses commercially available Ice 2000 (column 7, lines 55-58), and Elliott uses a software package (not named) that is “preferably installed on the hard disc of a user's computer” (column 5, lines 25-27).
Further, Elliott does not teach or suggest the creation of a construction plan using a software design tool, such as architectural CAD. In contrast, Elliott describes (col. 6, lines 43-50, and col. 10, lines 20-24) the scanning of a photograph or construction plan into a user's computer to produce a digital image, which is a completely different process.
Additionally, the systems of both Wakelam et al. and Elliott provide only an “estimate” for the products described therein, and not a final price. This is a very important distinction between the present invention and the teachings of Wakelam et al. and Elliott. For the reasons that follow, it is important to obtain a price, rather than an estimate. Generally, lending institutions will not rely upon an “estimate” when considering whether or not to make a construction loan because estimates are often extremely inaccurate, and such inaccuracy often results in large construction cost overruns and significant construction time delays. Further, a price is binding upon the person or entity that provides the price, whereas an estimate does not bind a person or entity to a particular price. Therefore, a person or entity that provides a price must honor their price (or may be sued for not doing so), even if the construction job for which the price was quoted ends up costing significantly more money than the price quoted, causing the person or entity that quoted the price to lose a significant amount of money. This is not true of an estimate, which does not bind a person or entity to a particular price. As can be seen, it is significantly more risky to provide a price in comparison with an estimate, which is the reason why contractors generally only provide estimates (i.e., they do not want to be bound to a particular price). Further, it is a much more complex process to provide a price (an assigned amount of money that is required to be paid in order to make a purchase) in comparison with an estimate (a rough calculation). Elliott itself acknowledges this fact by stating, “Calculating the material quantities and costs [of large construction projects] can be very complicated” (column 1, lines 25-26).
Moreover, neither Wakelam et al. nor Elliott teach or suggest the use of a zip code to determine price data for one or more construction plan elements. Although Elliott discusses zip codes, such discussion only relates to the average labor rate, the average price of land, the average cost of builder's risk insurance and building permit costs, not to construction plan elements (col. 4, lines 44-62). The foregoing items are completely different from construction plan elements, and the pricing of the foregoing items would be completely different from the pricing of construction plan elements.
In contrast with embodiments within the present invention, neither Wakelam et al. nor Elliott teach or suggest any of the following:
(1) inserting a price schedule into a construction plan;
(2) a price schedule that contains a list of construction plan elements with corresponding price quotes;
(3) the use of a CAD (Computer Aided Design) software product to create a construction plan;
(4) an add-on computer software code that imbeds a price schedule into a construction plan;
(5) the creation of a price schedule that includes one or two construction plan elements; or
(6) a plug-in (add-on) computer software code and a web site that permit a user to place an order to purchase one or more of the construction plan elements that are present in a price schedule.
U.S. Pat. No. 6,810,401 B2 (Thompson et al.) describes an automated configuration system (and method) for facilitating the configuration of desired products, services, or other assemblages that require users to gather and assimilate disparate knowledge of makes, models, types, features, codes, and prices of the desired product/service to be configured (abstract). In accordance with a preferred embodiment, configuration is facilitated through interaction of a user with a frame engine that performs frame-based inferences to discern stored knowledge of a product (or the like), as supplemented by a rules-based inference system (column 1, lines 30-34).
In contrast with embodiments within the methods and systems of the present invention, Thompson et al. describe a configuration system that does not use a plug-in (add-on) computer software code that runs as an internal component within a software design tool on a local computer, such as architectural CAD. Further, a construction product, such as a window or door, cannot be drawn in architectural CAD using the Thompson et al. system because the Thompson et al. system does not work in architectural CAD. In contrast, a construction product may only be cut and pasted into architectural CAD (in the same manner that a picture can be cut and pasted into a Word document). The configuration system of Thompson et al. is just drawing a picture on a computer. Moreover, the Thompson et al. system can only provide a price for one type of a construction product, such as a window, at a time, and provides a very slow process for providing such price. For example, in contrast with the methods and systems of the present invention, the system of Thompson et al. cannot provide a price for both a window and a door at the same time, or using the same computer software. Very disadvantageously, the Thompson et al. system must use a different type of software for each different type of construction product, for example, four different softwares for a window, a door, an acrylic glass block and a sky light, which is very time consuming and expensive.
In contrast with the Thompson et al. system, embodiments within the methods and system of the present invention uses a plug-in (add-on) computer software code that runs as an internal component within a software design tool on a local computer, such as architectural CAD. A product, such as a bay window, can be drawn in architectural CAD, and may then be imbedded into a wall of a room or structure, such as a Great Room. The window preferably gets sized, and then may optionally be “burned” into a wall, so that one can clearly see exactly what the window will look like when it is added to the room and embedded into the wall. The “burning” of the window into the wall is a function of the plug-in (add-on) computer software code that runs as an internal component within the architectural CAD program (or otherwise). The system that is described by Thompson et al. does not do this. Such system is not working in architectural CAD. Further, with the methods and systems of the present invention, changes may be made to the window (while embedded into the wall in a room or otherwise), and the changes to the window can then be clearly viewed (while the window is embedded into the wall in a room or otherwise). These methods and systems can provide a price (a final price, and not an estimate) very rapidly for one or more different types of construction or other products, which is “tricky” (i.e., not easily accomplished). With the methods and systems of the present invention, it is possible to obtain a price for a construction (or other) product, such as a window or door, from as many as fifteen or more different manufacturers and/or distributors (or others) at the same time, an average price in the geographic (or other) area, or any other type of a desired or required price. Further, the present invention optionally may use a zip code to obtain, and provide, price data for the purchase of one or more construction (or other) products, which includes a subtotal, tax and a final price. Very advantageously, the construction (or other) products can be purchased the same day (i.e. immediately).
None of Thompson et al., Wakelam et al. or Elliott teach or suggest any of the following steps, elements or limitations of embodiments within the methods and systems of the present invention:                (1) using an add-on (plug-in) computer software code that runs as an internal component within a software design tool on a local computer;        (2) an insertion of parametric symbols into a construction plan;        (3) using the add-on computer software code, transmitting data corresponding to each inserted parametric symbol from a local computer over the Internet to a remote server system;        (4) using a zip code and an add-on computer software code to access price data from a web site on a remote server system; or        (5) creating a price schedule from price quotes.        
Further, Thompson et al. does not teach or suggest: (1) providing a construction plan on a local computer; (2) creating a construction plan with a software design tool; or (3) providing on a local computer a palette that includes at least one parametric symbol.
The products that are described by Thompson et al. cannot be drawn in an architectural CAD (or other) software design tool. In contrast, they may only be assembled in such a tool by an architect (a different user with a different computer). With the use of human intervention (i.e. no automation), drawings that are created by the Thompson et al. system can be sent or exported to an architect, for example, using e-mail, and the architect can then cut and paste the drawings into an architectural CAD program that the architect is using. The Thompson et al. system merely allows one to cut and paste drawings of products into a CAD program. For example, a window could be drawn in Microsoft Word using its drawing tools, and such drawing could be considered to be a CAD drawing because it is a “computer assisted drawing” (i.e., a computer assists a user in drawing the window). Further, the drawing could be e-mailed to, an architect to be inserted into an architectural CAD program. However, in contrast with the methods and systems of the present invention, the user is not working in an architectural CAD program, and the drawing is not an add-on to an architectural CAD program.
In contrast with the above, the methods and systems of the present invention perform one or more sets of operations in a software design tool, such as architectural CAD, using an add-on (plug-in) computer software program. With this invention, no human intervention is generally required or desired (i.e., it is automated), and drawings can be “burned” (inserted) into a construction plan that has been designed using an architectural CAD program (or other software design tool).
Further, the Thompson et al. system can only be employed with one single product type, such as a window, whereas the methods and systems of the present invention can draw and price multiple different projects, such as a window, a door and an acrylic glass block, and rapidly provide comparison pricing for the various products from multiple different manufacturers and/or distributors (or others).
Moreover, like Wakelam et al. and Elliott, Thompson et al. does not teach or suggest the use of a zip code to determine price data for one or more construction plan (or other) elements. Additionally, Thompson et al. do not teach or suggest:
(1) placing an order to purchase one or more of the construction plan (or other) elements that are present in a price schedule (because no price schedule is created by Thompson et al.); or
(2) a system wherein an add-on (plug-in) computer software code and a web site permit a user to place an order to purchase one or more construction plan (or other) elements.
U.S. Patent Application Publication No. 2001/0047250 A1 (Schuller et al.) describes a computer-implemented method of visualizing a decorating project (abstract). The method includes rendering an image of a building space (e.g., a room) that includes a number of structural objects (such as doors, walls, and furniture) (abstract). The structural objects may be portrayed in the rendered image with visual characteristics that are determined by decorative materials (such as paint, fabric, or wallpaper) associated with the objects (abstract). Schuller et al. also describe a computer-implemented decorating system that includes a server operatively coupled to a memory, a database, and a network over which data can be exchanged with client computers (abstract). The memory includes software instructions to configure the server to retrieve modeling software from the database in response to requests from client computers, and to send the modeling software over the network to the client computers (abstract). The modeling software includes instructions to configure the client computers to model structural objects, to associate decorative materials with the structural objects, and to render an image of a building space (abstract). The rendered image portrays structural objects in accordance with visual characteristic of associated decorative materials (abstract).
In contrast with embodiments within the methods and systems of the present invention, the decorating system of Schuller et al.: (1) does not employ a plug-in (add-on) computer software code that runs as an internal component within a software design tool on a local computer, such as architectural CAD but, rather, uses a stand alone computer program; and (2) does not employ a zip code to provide any prices. Although Schuller et al. state that their implementations can include automated purchasing [of structural objects and decorative materials], Schuller et al. do not describe how this may be accomplished.
None of Thompson et al., Wakelam et al., Elliott or Schuller et al. teach or suggest any of the following steps, elements or limitations of embodiments within the present invention:                (1) using an add-on (plug-in) computer software code that runs as an internal component within a software design tool on a local computer (or otherwise);        (2) an insertion of parametric symbols into a construction plan;        (3) using the add-on computer software code, transmitting data corresponding to each (or one or more) inserted parametric symbol from a local computer over the Internet to a remote server system, or to an external, internal or other database (or otherwise);        (4) using a zip code and an add-on computer software code to access price data from a web site on a remote server system or from an external, internal or other database (or otherwise); or        (5) creating a price schedule from one or a plurality of price quotes.        
Additionally, Schuller et al. do not teach or suggest: (1) providing a construction plan on a local computer; (2) creating a construction plan with a software design tool; or (3) providing on a local computer a palette that includes at least one parametric symbol.
The teachings of Schuller et al. are clearly limited to the visualization of a decoration project (page 1, paragraphs [0006] and [0007]), and do not discuss construction projects.
Further, the “input images” that are discussed by Schuller et al. are obtained using a “digital image capture device,” such as a scanner, digital camera or video signal capture device, and not a software design tool, such as CAD (page 1, paragraph [0009]).
The method and system of Schuller et al., which are drawn to the decoration of a room with, for example, paint, wallpaper and fabric (page 2, paragraphs [0023] and [0028]), are much simpler, and quite different, in comparison with the methods and systems of the present invention, which are drawn to construction projects, and the pricing of one or more construction elements. Such pricing is quite “tricky” (i.e., is not easily accomplished).
Like Wakelam et al., Elliott and Thompson et al., Schuller et al. do not teach or suggest the use of a zip code to determine price data for one or more construction plan elements.
While Schuller et al. do discuss an automatic purchasing of furnishings and decorating materials (page 5, paragraph [0049], page 7, paragraph [0067], and claims 11, 12, 29 and 30), Schuller et al. do not specify the mechanism that is employed to procure pricing for such purchasing. The teachings that are present in Schuller et al. regarding an automated purchasing are very vague.
Moreover, Schuller et al. do not teach or suggest the use of an add-on (plug-in) computer software code to a software design tool that permits a user to pay for an order using a credit card.
A need in the architectural, construction and other industries currently exists for rapidly, efficiently and cost-effectively generating, and modifying, a set of construction (or other) plans for one or more construction (or other) elements, and a corresponding price quote schedule for such construction (or other) elements, in one general process, wherein a user can rapidly procure one, two, three, four, five or more comparative prices from one, two, three, four, five or more different manufacturers, distributors or others, which may be competitors, to determine the “best” (most competitive) final price for the various construction (or other) elements that will be used in the set of construction (or other) plans.